An Application Oriented Real-Time Algebra

ion, using a notion of re nement instead of bisimulation. In this paper we adopt the rst approach, using a timed process algebra for representing designs, and relying on model-checking (or at least hand veri cation of timed logic speci cations) as our proof method. Having said that, there is a large literature on timed logics and proof techniques (including modelchecking) [21, 22, 23, 24, 25, 18, 15], so we are going to leave aside this issue for the moment, and concentrate on the implications of using timed process algebras solely for representing designs. If an algebra is to be used as a design language, careful consideration must be given to how terms in the algebra (i.e. designs) are to be implemented. In our algebra, AORTA, more restrictions are placed on terms than in other algebras, precisely because the restrictions make implementation easier. Some of the most important di erences are because of the di culty of guaranteeing the time performance of a real-time system: parallel composition may only take place at the top level in order to x the number of processes, as time guarantees then become easier to give (see section 6); time bounds on performance and communication times can be given rather than precise gures. Implementing multiway synchronisation and broadcast events is di cult, particularly where performance gures are needed, so communication may only take place between pairs of explicitly named gates. The question may be raised as to whether such a restricted process algebra is still useful. We would argue that it is useful as an implementable design language (almost a programming language) which has a formal semantics, and so allows formal veri cation of the timing aspects of safety-critical systems from speci cation to implementation. Although more detailed justi cation needs to be given of the reasons for our choices (and more will be given in this paper), for the moment we move on to the development of a timed process algebra which is useful as a design language. 3 Introducing AORTA In keeping with the conclusions of the previous section we now introduce an application oriented real-time algebra (AORTA), which has certain features making it more suitable for representing designs of real-time systems (including timing information) than for giving speci cations. AORTA can almost be thought of as a programming language with a formal semantics, and although there are no automatic compilation techniques, there are ways of implementing AORTA designs. More of this in section 6; for the moment, we concentrate on the language as a process algebra. There are several ways of describing a process algebra: an informal description of the constructs of the language is very helpful, and a formal semantics is at least as important. There are also di erent ways of giving a formal semantics, the three main types of semantics being operational semantics, denotational semantics and algebraic semantics, these three being represented in the process algebra world by CCS, CSP and ACP respectively. These three presentation techniques are not mutually exclusive | a lot of work done with CCS is concerned with equational (algebraic) reasoning, CSP has been given an operational semantics, and operational transition rules are used in ACP | so a good conceptual understanding can be as important as a detailed knowledge of the formalism concerned. In this paper we use operational semantics given by transition rules, but before that is an informal introduction to AORTA and 3 some examples. 3.1 Concrete Syntax and Informal Semantics Of the common untimed algebras, AORTA is most similar to CCS, both in notation (. for action pre xing and + for choice) and in semantics (only twoway synchronisation allowed), but even apart from the time considerations there are some important di erences. One of the restrictions placed on the language to aid implementation is that the number of processes in a system may not vary, and this restriction is enforced by insisting that all parallel composition should happen at the top level. This gives rise to two levels of description: one for the sequential processes within a system, and another for the parallelism and connectivity of the system. Restricting systems to a xed number of processes is not uncommon in real safety-critical systems, and the limitations imposed are partly justi ed by the veri able implementation techniques described in section 6. Some familiarity with CCS is assumed in the following. 3.1.1 Sequential Processes The description of sequential processes is where the relation of AORTA to CCS is shown most strongly. Actions can be o ered, which must be matched by a communicating partner before the process can proceed, and a choice may be o ered between a number of actions. As in CCS, action pre x and choice (sometimes called summation) are represented by . and + respectively, with 0 for the null process which o ers no actions. Recursion can be written using the same equational format as used in CCS (e.g. A = a.A), but all recursion must be guarded (i.e. all process names must appear inside an action pre x). The other constructs do not have analogues in CCS, and are concerned with including time information into the process description. There are two constructs which are used to introduce time, and each of these has a deterministic and nondeterministic form. The rst construct is a delay which causes the process to pause for the amount of time speci ed, during which time no actions are o ered | time consuming operations like computation are represented in this way. As precise times are not always known, the delay may be speci ed with an upper and lower bound, rather than a precise gure. A process which delays for precisely t time units before behaving like S is written [t]S, and if the delay is bounded by times t1 and t2 the process is written [t1,t2]S. The second construct is a timeout extension to summation, so that if none of the branches of the choice are taken up within the given time, control is transferred to another branch. Again, depending on how the timeout is implemented a precise gure for the time at which control is transferred may not be available, so an interval of possibilities can be given instead. A choice process S which times out to process T if no communication happens within time t is written S [t> T, and if the time is bounded by t1 and t2 it is written S [t1,t2> T. Having given the time behaviour of our new constructs it is necessary to go back to describe the time behaviour of pre x and choice. A simple pre x forces the process to wait until communication can take place on the named channel, so the process a.S can wait for any length of time without changing, provided communication is not possible. Consideration of how a choice should behave in time leads us to restrict choice to processes which start with an action 4 pre x a.S choice S1 + S2 delay [t]S bounded delay [t1,t2]S timeout (S1 + ... + Sn)[t>S bounded timeout (S1 + ... + Sn)[t1,t2>S data dependent choice S1 ++ S2 recursion equational de nition Table 1: Summary of concrete syntax for sequential processes pre x or another choice. If a choice were allowed between processes that began with a delay, e.g. [3]a.0 + [2]b.0, then either the choice would have to be resolved at the rst instant of time, leading to time nondeterminism (and a very counter-intuitive system), or both branches of the choice would have to run concurrently, which goes against the idea of a sequential process. As both of these are unacceptable, we restrict the language so that choices can only be made between processes which start with an action pre x or another choice. One of the reasons for uncertainty in the execution times of programs is that there is no information available about the data on which the program is running | we either don't know what the data is or we choose to ignore it to avoid complexity. At the moment no attempt is made to model data in AORTA, so any branch in a sequential process which depends purely on data (in particular on the outcome of a computation) rather than on communication (which is handled by the existing choice) appears to be nondeterministic. To allow for such branches, a data dependent (or nondeterministic) choice can be o ered between two (or more) processes: such a choice is written P++Q, and is similar to the nondeterministic choice P uQ of CSP. In summary, a sequential process may be constructed from action pre xes, summations (choices over pre xed processes), time delays, timeouts over choices, nondeterministic choices and guarded recursion. The syntax is summarised in table 1. Each process has a behaviour in time which says which actions it is prepared to engage in, or in other words, at which of its gates it is prepared to engage in communication. Obviously, for communication to take place there has to be more than one process in the system | the way that a system is constructed from its component processes is kept separate from process de nition in AORTA. 3.1.2 Parallel Composition and Communication Apart from xing the number of processes in a system in order to provide reliable timing predictions (see section 6), there are other steps which can be taken to aid implementability. One area which is crucial to process algebras and realtime systems is inter-process communication, and this is perhaps where AORTA is most di erent from existing process algebras. In all of the common process algebras the communication actions of any process are visible to any other process unless explicitly hidden or restricted, which leads to problems on two fronts. From an implementation point of view this requires some way of broadcasting all available actions to all processes. Even more problems are encountered in implementing the multiway synchronisation 5 of CSP and LOTOS, as witnessed by the restriction to two-way communication in occam [26] and the need for a special protocol in LOTOS [27]. For a simple system, which is all we can hope to formally verify at the moment, the mechanism for providing such communication facilities may be an excessively costly overhead, both in terms of implementation and veri cation. The availability of all actions to all processes can also cause problems in veri cation, as checking for all possible communications requires testing of each pair of processes for communication on each action, leading to an explosion in the number of checks to be made. This explosion can be contained by restricting communication to a named set of channels between processes. There is an analogy here with sequential programming, where the techniques of object-oriented and functional programming have tried to limit the means of access to each part of the program data, making reliable and veri able design easier. As AORTA is to be used as a kind of parallel programming language which admits veri cation, similar restrictions on the availability of program data and communication will ease veri cation. In the light of these problems, AORTA requires explicit connections to be made for a communication to become possible, and these connections are made statically in the system de nition. Each process has a set of named gates (like the syntactic sort of CCS), and communication links between processes are made by explicitly naming pairs of gates to be linked. By using explicit linking the restriction or hiding operators of other process algebras are not needed, and by allowing gates with di erent names to be linked, renaming operators become unnecessary. The use of explicit connections may appear to restrict the use of compositional veri cation techniques, such as are described in [25], which could cause problems given the complexity of the model-checking problem. However, as we shall see later, the semantics of AORTA is layered, separating the sequential process behaviour from the derived system behaviour. At the sequential process level, all communications, internal and external, are represented in the same way, allowing abstract reasoning about individual processes and compositional reasoning at the system level. Two or more processes may be put in parallel using |, so that P|Q|R represents three processes in parallel, where each of P, Q, and R is a sequential process. In order to enable communication, a collection of processes may have some pairs of gates linked, using a connection set written in angle brackets after the processes. An element of the connection set is a pair of gates to be connected, but this can be abbreviated to a single name if both ends of the link have the same name. In section 4, there are some examples to show the notation in practice, and then we give a more abstract syntax and a formal semantics for AORTA in section 5. 4 Examples in AORTA In this section there are two examples to show how AORTA can be used. One feature of the concrete syntax just given is that it uses only standard ASCII characters, and this is emphasised by using typewriter script when using the concrete syntax. The order of binding (tightest rst) for sequential processes is . [..] + [..> ++ and then recursion, and parallel composition constructs | <..> bind most loosely of all. As usual, brackets can be used to override this ordering. 6 4.1 A Mouse Button One system which cannot be expressed in an untimed algebra is that of a mouse which can either be clicked or double-clicked. If the mouse button is clicked twice within 250ish milliseconds then a double-click event will be o ered; otherwise a press of the button will yield a single click event. This system quite naturally uses a timeout in its implementation, which is re ected in its expression in AORTA: Mouse = click?.(click?.double!.Mouse)[0.245,0.255>single!.Mouse Mouse is a recursive process, with recursion de ned using an equational format. The timeout [0.245,0.255> ensures that if a click is not followed by another within about 250 milliseconds then a single click is o ered. If the second click occurs within 245 milliseconds of the rst then it will de nitely be accepted as a double, and it may be accepted as such up to 255 milliseconds after the rst. An implementation would follow quite easily from this, with a process which waited for a click, and then read a clock, before waiting for either another click or the current clock value to exceed the old one by 250 milliseconds. Depending on which happens rst a double or single click event will be o ered before returning to wait for another click. As long as the clock was accurate to within 5 milliseconds it would have behaviour modelled by the AORTA expression, so any reasoning done on that expression would apply to the implementation. Note that we use gate names with an exclamation or question marked attached, corresponding to `output' and `input', but that this is purely for the ease of the reader and is not required. 4.2 A Car Cruise Controller A standard example of a real-time safety-critical system is a cruise controller for a car, which was used as an example for comparing di erent methodologies, and is outlined in [28]. An extract from the speci cation (taken from [28]) is The cruise control function is to take over the task of maintaining a constant speed when commanded to do so by the driver. The driver must be able to enter several commands, including: Activate, Deactivate, Start Accelerating, Stop Accelerating, and Resume. The cruise control function can be operated any time the engine is running and the transmission is in top gear. When the driver presses Activate, the system selects the current speed, but only if it is at least 30 miles per hour, and holds the car at that speed. Deactivate returns control to the driver regardless of any other commands. Start Accelerating causes the system to accelerate the car at a comfortable rate until Stop Accelerating occurs, when the system holds the car at this new speed. Resume causes the system to return the car to the speed selected prior to braking or gear shifting. The driver must be able to increase the speed at any time by depressing the accelerator pedal, or reduce the speed by depressing the brake pedal. Thus, the driver may go faster than the cruise control setting simply by pressing the accelerator pedal far enough. When the pedal is released, the system will regain control. Any time the brake pedal is depressed, or the transmission shifts out of top gear, 7 the system must go inactive. Following this, when the brake is released, the transmission is back in top gear, and Resume is pressed, the system returns the car to the previously selected speed. However, if a Deactivate has occurred in the intervening time, Resume does nothing. It also adds that in the implementation The system controls the car through an actuator attached to the throttle. This actuator is mechanically in parallel with the accelerator pedal mechanism, such that whichever one is demanding greater speed controls the throttle . . . For smooth and stable servo operation the system must update its outputs at least once per second. An AORTA implementation of such a system can be given by breaking the system into four processes: the speedometer system, the controller system, the throttle system and the brake and gear system. Looking rstly at the speedometer system, we assume that there is a measurement that can be made which will give the speed, but the acceleration is also needed (for the Accelerate function), and this is calculated and o ered by this process. About every half a second the speed is reread and a new value for the acceleration calculated, and for the rest of the time there are two channels on which the speed is available (one for the controller and one for the throttle mechanism) and one channel with the acceleration. This is written in AORTA as Speedo1 = (speedout1!.Speedo2 + speedout2!.Speedo2 + accelout!.Speedo2)[0.4,0.5>Speedo2 Speedo2 = speedin?.[0.2,0.3]Speedo1 The delay [0.2,0.3] corresponds to the time taken to calculate the new value for the acceleration. The system which monitors the brakes and gears is also quite simple, and simply checks the state of the gears and brakes, and depending on what it nds o ers a fast! action, indicating that everything is ne or a slow! action, indicating that either the brakes are on or the transmission is not in top gear. The choice as to which to o er depends on the data which comes from gearstate? and brakestate? actions, and so is represented by a data dependent choice ++. As in the speedometer, new readings are taken about every half a second, giving the de nition Brakengear1 = (fast!.Brakengear1)[0.4,0.5> gearstate?.brakestate?.(Brakengear1 ++ Brakengear2) Brakengear2 = (slow!.Brakengear2)[0.4,0.5> gearstate?.brakestate?.(Brakengear2 ++ Brakengear1) A slightly more complex system is the throttle system, which has to monitor the speed and ensure that it is kept at the speed speci ed by the controller, and which sometimes has to enter an accelerating phase, when it must keep control of the acceleration. Because of the parallel accelerator pedal mechanism,manual control will be resumed if the accelerator pedal is down further than the cruise 8 control actuator, and in particular, if the actuator is set to zero the driver has complete manual control over the throttle. The output of the throttle controller system is the setthrottle! action, which passes a value for the actuator to be set at. In usual operation, the system monitors the speed (via getspeed?) and adjusts the throttle about every half a second. It may also allow a new speed to be set (by setspeed?), the speed to be set to zero (resetspeed?), or put the system into an accelerating phase (accelon?). During the accelerating phase the acceleration is monitored and adjusted until told to stop accelerating (acceloff?), when the current speed is read for use as the new control speed and control returned to the usual state. If a resetspeed? is encountered, the system waits for a new value to be passed via setspeed? before returning to usual operation. All of this is described in AORTA by Throttle1 = (setspeed?.Throttle1 + accelon?.Throttle2 + resetspeed?.Throttle3)[0.4,0.5> getspeed?.setthrottle!.Throttle1 Throttle2 = (acceloff?.getspeed?.Throttle1)[0.4,0.5> getaccel?.setthrottle!.Throttle2 Throttle3 = setthrottle!.setspeed?.Throttle1 The system which has overall control, and which accepts commands from the driver (or at least from an interface to the driver) has a more complicated logical structure, but does not have any real computation to do nor any time dependent behaviour in the form of timeouts. There are four major states of the controller, corresponding to the controller being inactive, the controller being active, the controller being in an accelerating state, and the controller waiting for a Resume after the brake being pressed or the transmission leaving top gear. Before entering an activated state, the controller has to check that the brakes are not on and that the transmission is in top, which it does by looking for a fast? from the brake and gear system | if a slow? is encountered the system must be reactivated. The speed is checked, and if it is greater than 30 mph the controller becomes active, otherwise the system must be reactivated. As this decision is based on the data about the speed, it is modelled by a data dependent choice ++, giving the structure Cont1 = activate?.(fast?.checkspeed?.(Cont1 ++ setspeed!.Cont2) + slow?.Cont1) Once activated, the system must allow itself to be deactivated, or suspended due to a brake/transmission event, or put into the accelerating step. This is achieved by Cont2 = (deactivate?.setspeed0!.Cont1 + startaccel?.Cont3 + slow?.Cont4) During acceleration the system can be deactivated, or stopped from accelerating, or suspended by a brake/transmission event Cont3 = accelon!.(deactivate?.acceloff!.setspeed0!.Cont1 + stopaccel?.acceloff!.Cont2 + slow?.acceloff!.Cont4) Finally, if a brake/transmission event occurs, the speed must be reset and resumption or deactivation allowed, checking that the brakes and gears are in order if necessary. 9 Cont4 = setspeed0!.(resume?.fast?.setspeed!.Cont2 + deactivate?.Cont1) This design is certainly not the only one that could be employed, and probably contains some logical errors (for instance, if a slow event occurs followed by a resume before the brakes and gears are OK the system may deadlock), but it does show how AORTA can be used for designing a such a system. This initial design may be simulated to iron out any obvious problems, and it may be checked against a formal speci cation for inconsistencies or errors. The whole of the design (including communication links) is given by Cont1 = activate?.(fast?.checkspeed?.(Cont1 ++ setspeed!.Cont2) + slow?.Cont1) Cont2 = (deactivate?.setspeed0!.Cont1 + startaccel?.Cont3 + slow?.Cont4) Cont3 = accelon!.(deactivate?.acceloff!.setspeed0!.Cont1 + stopaccel?.acceloff!.Cont2 + slow?.acceloff!.Cont4) Cont4 = setspeed0!.(resume?.fast?.setspeed!.Cont2 + deactivate?.Cont1) Speedo1 = (speedout1!.Speedo2 + speedout2!.Speedo2 + accelout!.Speedo2)[0.4,0.5>Speedo2 Speedo2 = speedin?.[0.2,0.3]Speedo1 Brakengear1 = (fast!.Brakengear1)[0.4,0.5> gearstate?.brakestate?.(Brakengear1 ++ Brakengear2) Brakengear2 = (slow!.Brakengear2)[0.4,0.5> gearstate?.brakestate?.(Brakengear2 ++ Brakengear1) Throttle1 = (setspeed?.Throttle1 + accelon?.Throttle2 + resetspeed?.Throttle3)[0.4,0.5> getspeed?.setthrottle!.Throttle1 Throttle2 = (acceloff?.getspeed?.Throttle1)[0.4,0.5> getaccel?.setthrottle!.Throttle2 Throttle3 = setthrottle!.setspeed?.Throttle1 Cruisesys = (Cont1|Speedo1|Brakengear1|Throttle1) <(Cont1.checkspeed?,Speedo1.speedout2!), (Cont1.acceloff!,Throttle1.acceloff?), (Cont1.accelon!,Throttle1.accelon?), (Cont1.setspeed0!,Throttle.restspeed?), (Cont1.setspeed!,Throttle1.setspeed?), (Cont1.slow?,Brakengear1.slow!), (Cont1.fast?,Brakengear1.fast!), (Speedo1.accelout!,Throttle1.getaccel?), (Speedo1.speedout1!,Throttle1.getspeed?)> The parallelism and communication channels of the system are represented graphically in gure 1. Another small example, of a temperature conversion process, is described in [29]. 10 Cont Speedo checkspeed? speedout2! acceloff! accelon! setspeed! fast! slow! slow? fast? getspeed? getaccel? speedout1! speedin? brakestate? gearstate? Brakengear speedin? brakestate? gearstate? activate? deactivate? startaccel? stopaccel? resume? accelout! accelon? acceloff? setspeed? setspeed0! resume? stopaccel? startaccel? deactivate? activate? Throttle setthrottle! setthrottle! resetspeed? Figure 1: Parallelism and Connectivity of Cruisesys 11 5 Formalising AORTA 5.1 The Abstract Syntax The syntax presented here is an abstract syntax, terms of which may be expressed in the concrete syntax given in section 3.1: the translation between the two is mostly straightforward, but some of the ner points are dealt with later. A system is expressed as a product of sequential processes, each of which has a set of gates; gates of processes can be connected pairwise to allow communication. A system expression is then written P =Yi2I Si < K > where each Si is a sequential process, and K is a set of unordered pairs of gates to be linked. Each gate is speci ed by its process (i.e. an element of I) and its name, and may be connected to at most one other gate. At this level the communicationdelay bounds for each gate must also be speci ed; for linked pairs the bounds will be the same and will depend on internal communication delays, but for unlinked gates (i.e. gates that communicate with the environment) the delay will depend on what is being accessed and how. The delay bounds are speci ed by giving a function delays which takes a gate identi er, and returns an interval of possible communication delay times. This function is de ned at the system level, when the details of how gates of processes are to be connected is known. The structure of sequential expressions is given by the syntax S ::=Xi2I ai:Si j [t]S j Xi2I ai:Si >tS j [t1; t2]S j Xi2I ai:Si >t2 t1S j Mi2I Si j X where t, t1 and t2 (t1 < t2) are time values taken from the time domain (either the positive reals or the naturals), and X is taken from a set of process names used for recursion. These constructs correspond to action summation, deterministic delay, deterministic timeout, nondeterministic delay, nondeterministic timeout, nondeterministic choice and recursive de nition respectively. There is a subset of these sequential expressions, the regular expressions, which is de ned to be the set of expressions which evaluate to true under the function regular given in gure 2. Informally, regular expressions are those expressions which do not involve any nondeterminism (via delays, timeouts or nondeterministic choices) before the rst action summation, and which contain only guarded recursion | the condition on guardedness is that all recursion should be guarded once reformulated as a xed point. The translation of a concrete syntax term into the abstract syntax is fairly direct, but does raise some interesting points. Although we do not wish to deal with bisimulations, for reasons already stated, there is an equivalence which yields some of the less interesting equalities on terms, namely syntactic equality on abstract syntax terms, modulo arithmetic and set equality. Because choice and parallel composition are indexed by sets in the abstract syntax, it does not matter in which order the subterms appear in the concrete syntax. This renders laws such as the commutativity and associativity of the concrete syntax + and | immediate, as well as the law P + 0 = P, where 0 has the usual translation of summation over the empty set. 12 regular(Xi2I ai:Si) = true regular([t]S) = regular(S) regular(Xi2I ai:Si >tS) = regular(S) regular([t1; t2]S) = false regular(Xi2I ai:Si >t2 t1S) = false regular(Mi2I Si) = false regular(X) = false Figure 2: De nition of regular 5.2 The Formal Semantics In order to de ne the semantics of system expressions, the semantics of regular expressions is given rst. As usual for an operational semantics, a set of transition rules is given, from which is constructed the least relation to satisfy all of the rules. This semantics depends heavily on the Poss function, which describes all of the possible ways in which a non-regular (i.e. nondeterministic or recursive) expression could be resolved into a regular expression. Rules are only de ned for action summation, timeout and deterministic delays because all other terms are non-regular; note that all terms on the right hand side of transition arrows are regular (in particular, all elements of Poss(S) are regular), so the transition relation is well-de ned on regular expressions. There are two types of transitions, namely action transitions, written a ! where a is a gate name, and time transitions, written (t) ! where t is a value in the time domain. The rules are given in gure 3, and the auxiliary function Poss is de ned in gure 4. When an action transition takes place all nondeterminism up to the next action is resolved, by the use of the Poss function. This is not only convenient from a theoretical standpoint, but does correspond to the situation in a real system. From a theoretical point of view, it avoids the problem of time nondeterminism. Practically speaking, the nondeterminism comes from a lack of knowledge about data in the system, and a lack of predictability as regards scheduling and communication delays; once a process has communicated, all of its data is xed until the next possible communication, and if a scheduling mechanism such as that outlined in section 6 is used then once the starting time of a computation or communication is known, its completion time can be calculated exactly. Each system expression is described as a product of (regular) sequential expressions, and the transitions of a system are derived from the transitions of each of its component processes as would be expected. The transition rules for system expressions are given in Fig. 5, but the transition system cannot be formed as the usual least relation, because of the negative premise of the rule for delay. Problems with negative premises in transition system speci 13 Pi2I ai:Si aj ![t0]S0 j j 2 I; S0 j 2 Poss(Sj) t0 2 delays(aj ) Pi2I ai:Si (t) !Pi2I ai:Si [t]S (t0) ![t t0]S t0 < t [t]S (t) !S Pi2I ai:Si >tS aj ![t0]S0 j j 2 I; S0 j 2 Poss(Sj ) t0 2 delays(aj ) Pi2I ai:Si >tS (t0) !Pi2I ai:Si >t t0S t0 < t Pi2I ai:Si >tS (t) !S S1 (t1) !S2 S2 (t2) !S3 S1(t1+t2) ! S3 Figure 3: Transition rules for regular expressions Poss(Xi2I ai:Si) = fXi2I ai:Sig Poss([t]S) = f[t]S0jS0 2 Poss(S)g Poss(Xi2I ai:Si >tS) = fXi2I ai:Si >tS0jS0 2 Poss(S)g Poss([t1; t2]S) = f[t]S0jt 2 [t1; t2]; S0 2 Poss(S)g Poss(Xi2I ai:Si >t2 t1S) = fXi2I ai:Si >tS0jt 2 [t1; t2]; S0 2 Poss(S)g Poss(Mi2I Si) = fS0 iji 2 I; S0 i 2 Poss(Si)g Poss(X) = Poss(S) if X def = S Figure 4: De nition of Poss 14 Internal Communication Sj a !S0 j Sk b !S0 k Qi2I Si < K > !Qi2I S0 i < K > (j:a; k:b) 2 K S0 i = Si if i 6= j; k External Communication Sj a !S0 j Qi2I Si < K > a !Qi2I S0 i < K > j 2 I (j:a; ) 62 K S0 i = Si if i 6= j Qi2I Si < K > 6 ! Delay 8i 2 I:Si (t) !S0 i Qi2I Si < K > (t) !Qi2I S0 i < K > 8t0 < t:Qi2I Age(Si; t0) < K > 6 ! Figure 5: Transition rules for system expressions cations are discussed in [30], and a technique called strati cation is provided to give a meaning to such transition systems. Applying this to AORTA, all of the transitions of sequential expressions should be worked out rst, then all internal communications of system expressions, and nally the time transitions and external communications of system expressions. By applying the transition rules in three stages we ensure that no transition's validity depends on its own negation, as may be the case in a transition system with negative premises; this layering is equivalent to a three layer strati cation. For further details, see [30]. The rule for external communication also has a negative premise attached, in order to enforce a simple priority on actions: here we insist that internal communications be preferred to external ones, as the permanent availability of some environment actions may make choices unfair. A similar technique can be used to attach a full set of priorities to the actions, both internal and external, allowing one internal communication to be preferred to another and so on. In order to give a well de ned semantics to this, negative premises can be attached to all actions other than the highest, stating that the communication may not take place if any higher priority action is possible. A larger strati cation is then used, with a di erent stratum attached to each priority level, as well as strata for sequential processes and time transitions. As well as a strati cation, the rule for delay uses an auxiliary function, Age, which is de ned on regular expressions as in gure 6. This function is really meant to make the side-condition easier to express, as the Age function takes a process and a time, and returns the state of the process after having delayed for the speci ed time. This is captured in the theorem Theorem 1 For any regular sequential expressions S and S0 and any time t S (t) !S0 () Age(S; t) = S0 where = is syntactic identity modulo equality on time expressions 15 Age(Xi2I ai:Si; t0) = Xi2I ai:Si Age([t]S; t0) = 8<: [t t0]S (t0 < t) S (t0 = t) Age(S; t0 t) (t0 > t) Age(Xi2I ai:Si >tS; t0) = 8<: Pi2I ai:Si >t t0S (t0 < t) S (t0 = t) Age(S; t0 t) (t0 > t) Figure 6: De nition of Age The intuitive interpretation of the transition system formed by these rules is worth mentioning, as there is often some ambiguity, particularly in untimed algebras, as to what it all means. The two types of transition, a ! and (t) ! correspond to ability to communicate and ability to age. If S a !S0 then S is ready to communicate externally on gate a, and if this communication takes place the process will then become S0. If a system can communicate internally then it does (maximum progress principle, as enforced by the side condition on the delay rule), and this is represented by the distinguished action !. If more than one action is possible then a nondeterministic choice is made between the available actions. The (t) ! transition describes how a system or process may age in time, and it is a property of the system that any process has only one way in which to age: in other words, it is time deterministic. The behaviour of a system is then represented by a a series of transitions, with the behaviour of the environment a ecting which external communication events ( a !) take place. As each communication has a minimum (non-zero) delay attached, only nitely many external events can occur within a nite time, so the system has nite variability; as the number of processes is xed, it also has bounded variability [17]. This formal semantics is also presented in [31], along with a discussion of the problem of verifying the correctness of AORTA designs. 5.3 The Mouse Button Revisited The mouse button process, which was described in section 4.1, is used here to show how the formal semantics of a process can be derived. Its de nition was Mouse = click?.(click?.double!.Mouse)[0.245,0.255>single!.Mouse To de ne a system which uses this mouse, let us use a very simple computer, which reacts to one or two clicks on the mouse by performing a piece of computation. Computer = one?.[0.4,0.5]Computer + two?.[1.2,1.4]Computer Putting these in a system, we get 16 ( Mouse | Computer ) <(Mouse.single!,Computer.one?), (Mouse.double!,Computer.two?)> and de ne the delays function to give the interval [0:001; 0:003] for all gates (internal and external). Firstly, the sequential transitions within the system can be worked out, using the rules of gure 3. As both Mouse and Computer begin with choice, the time transitions are very straightforward Mouse (t) !Mouse Computer (t) !Computer and the action transitions include Mouseclick? ! [0:0025](click?:double!:Mouse)[0:249> single!:Mouse Computerone? ![0:0012][0:41](one?:[0:4;0:5]Computer + two?:[1:2;1:4]Computer) Computertwo? ![0:003][1:38](one?:[0:4;0:5]Computer + two?:[1:2;1:4]Computer) There are many more possible action transitions of Mouse and Computer, as the Poss function allows the resolution of nondeterminism to any time value within the bounds, but they can only be via a click?, one? or two? action. The initial system transitions are derived from the initial sequential transitions by the rules of gure 5. As click? does not appear in the connection set, and it is the only possible action transition of Mouse, no internal communication ( transitions) can take place. Also Age(Mouse; t) = Mouse and Age(Computer; t) = Computer so we can derive the time transition ( Mouse j Computer ) (t) !( Mouse j Computer ) as well as the action transition ( Mouse j Computer )click? ! ( [0:0025](click?:double!:Mouse)[0:249> single!:Mouse j Computer ) If the mouse button is not pressed again, the subsequent time transitions of the mouse process are [0:0025](click?:double!:Mouse)[0:249> single!:Mouse(0:0025) ! (click?:double!:Mouse)[0:249> single!:Mouse(0:249) ! single!:Mouse For these rst 0.2515 seconds, only the click? action is available, which is not internally connected, so we can derive the system time transition ( [0:0025](click?:double!:Mouse)[0:249> single!:Mouse j Computer )(0:2515) ! ( single!:Mouse j Computer ) 17 At this point an internal communication between single! and one? becomes available, so no more time transitions can take place until the following transition has taken place ( single!:Mouse j Computer ) ! ( [0:0018](click?:(click?:double!:Mouse)[0:245;0:255> single!:Mouse) j [0:0012][0:41](one?:[0:4; 0:5]Computer + two?:[1:2;1:4]Computer ) The computer can will now execute for 0.41 seconds after its communication delay, so that after a time transition of 0.4112 we are back to the starting point of ( Mouse | Computer ) 6 Implementing AORTA Designs One of the motivations for this work is to provide a route for building veri ed real-time systems from speci cation to implementation. Having put aside timed process algebras as broad spectrum languages, we have chosen to use timed logic for speci cation, and AORTA as a design language; it remains to show how AORTA designs can be implemented, and how these implementations can be veri ed to match their designs. The implementation described in this section is not meant as the only way to implement AORTA designs, but rather to show that the kind of performance modelled by AORTA can be achieved by real systems. The most challenging part of implementing a timed algebra lies in the timing aspects, and it is on these aspects that we concentrate. Perhaps the most important thing to achieve in a real-time system is predictability: if timing requirements are to be as important as the functional requirements we have to give them equal status, and no one would be happy with a database which `usually' keeps its integrity, or a structural analyser that works `provided you don't give it too much data at once'. If enough assumptions cannot safely be made about an environment to guarantee that a system will function safely, then that system is not safe to use in such an environment. There are those who prefer to allow some possibility of failure within a system and justify that failure is so unlikely as to render the system e ectively safe, but for two reasons we prefer to stick to a more predictable approach: Software, at least, does not wear out or fail at random, so there is no reason why this part of a system should not be predictable. The full stochastic analysis of a system is very expensive, and relies on assumptions about independence of events which cannot be veri ed. (In particular, the behaviour of a system in extremal circumstances is of most interest, and this is when assumptions may be least valid.) Admittedly, there are elements in a system which are unpredictable, such as hardware failure or noisy communication, but we prefer to account for these separately and do most of our analysis on a predictable basis. Having said all this, we return to our earlier point that precise times can seldom be predicted for a system, and that bounds are much easier to achieve. Note that we claimpredictability is important, not determinism: a system whose 18 performance is bounded is predictable, so we present a scheme for producing predictable systems in the absence of hardware failures. There are three areas where an implementationof an AORTA design has time bounds to achieve: in sequential execution, in communication, and in timeouts. As far as sequential execution goes, we assume that bounds can be placed on the processing time required for a piece of sequential code (see [32, 33, 34]), so if the parallelism within a system is to be implemented solely by distributing the processing there is no more to do as processing time is the same as elapsed time; the situation is more interesting when multitasking on a single processor is to be used, and processing time for a process is di erent from elapsed time. The scheduler described here is very predictable, if not the most e cient under light loads. It should be noted, though, that it is under heavy processing loads that prediction becomes most important, and this scheduler has the pleasing property that the more processing required the more e cient it becomes. The basis is a very simple round-robin scheduler which switches processes at a xed rate, regardless of their state of execution. This makes the performance of each process independent of the others, (as opposed to the situation in a priority based scheduler,) except when dependence is explicitly introduced by waiting for communication, and in a way makes each process look like it is being executed on a separate processor. In a system with a xed number of processes (such as AORTA) the time between schedules for any process is xed, as is the amount of time it gets. Figure 7 shows the schedule for two processes: the l labels refer to the length per schedule, and d to the time (or distance) between calls, with the scheduler being process 0. A more sophisticated scheduling mechanism may be more e cient, but is likely to be much less predictable. The arguments as to which scheduling policy is `best' are long and not necessarily enlightening here | for the moment we only want a scheduler that `will do'. For discussion of some of the issues see [35, 36], although their conclusions are not necessarily in line with ours. In general, if process i needs t units of processing time to complete a task, bounds can be put on the amount of real time needed to complete. The minimum elapsed time is required if measurement starts at exactly the point at which the process becomes scheduled (as this minimises the amount of time spent waiting). In this case the amount of time spent waiting is bt=l(i)c (d(i) l(i)) (where bxc is the largest integer such that bxc x), so the total elapsed (real) time is t+ bt=l(i)c (d(i) l(i)) In the worst case time is measured from the point at which the process has just become descheduled, in which case there is a whole extra idling cycle, giving an elapsed time of t+ (bt=l(i)c + 1) (d(i) l(i)) Putting these bounds together with the bounds on processing time for our sequential processes we can arrive at bounds on elapsed time for the execution for a section of code running in a process. As well as allowing each of the processes enough processing time to complete their tasks within the time bounds required, there also has to be a way of implementing the communication or synchronisation between processes. Many timed process algebras enforce the maximum progress principle ( urgency), where 19 ------l(0) l(1)l(2)d(0)d(1)d(2)SchedulerProcess 1Process 2Figure 7: Predictable process schedulingcommunication between processes happens as soon as both parties are ready, asthis makes the semantics simpler, and ensures that things like timeouts can bemodelled (if communication may stall inde nitely a timer becomes useless). InAORTA immediate communication is not necessary, as it is virtually impossibleto implement, but a time bound is put on communication by the delay in therule for action transitions of sequential processes, shown in gure 3.This can be implemented relatively easily, especially with explicit connectionof gates. An area of memory shared by all of the processes and the scheduler isused, with a region for each communication channel (i.e. a linked pair of gates).Inside each such region there should be a bit for each gate, corresponding toreadiness to communicate. These are usually both set to zero, but when aprocess wishes to communicate it sets the relevant bit to one, and waits for itto return to zero before continuing. The scheduler is the only process with thepower to reset a bit, and each time it is called it runs through all of the channelsand resets to zero any pair of ones. In this way there is an upper bound on theamount of time before an enabled communication occurs, essentially the lengthof the time slice d(0). Note that values can also be passed by simply havinga value store associated with each communication channel, written to by oneof the processes and read by the other on completion of the communication.Choice does complicate the issue, as some communication possibilities must beremoved when a choice is resolved, and this leads to some nondeterminism inthe amount of time the scheduler takes to complete its communication check;again this can be bounded, so the system remains predictable. Because the actof setting a bit can be atomic (in terms of CPU instructions) and all of theresetting is done by the scheduler which cannot be interrupted, no problemsarise from preemption of processes.Timeouts in AORTA are merely an extension of choice, and can be imple-mented as such. When a choice with a timeout is started the local clock canbe read and the time at which the timeout will expire can be calculated. If20 this time is stored somewhere that the scheduler can see it, then the sched-uler can compare any timeouts with the current time and adjust the relevantprocess control accordingly, as well as removing any redundant choices from anactivated timeout. As before, bounds can be placed on the time at which anyparticular timeout will expire, but exact gures cannot necessarily be given.This general scheme then allows bounds to be placed on sequential executiontimes, communication delays and timeout events so that an implementation canbe shown to have the same timing characteristics of an AORTA design. If thedesign is also shown to correct with respect to a timed logic speci cation thenwe can can be satis ed that the implementation is also correct with respect tothat speci cation. For a more detailed timing analysis of this kernel, and adescription of some of the implementation details, see [37].7 ConclusionIn this paper we have argued for and presented a timed process algebra whichis amenable to formal veri cation and yet can only represent systems which canbe implemented; some indication as to how these systems might be realised inpractice is also given. AORTA is certainly not the rst timed process algebra(the introduction references many others), or the rst attempt to design timingpredictability into a system from the start [38], or the rst attempt to provide a(formally based) middle ground between implementation and speci cation [39]:the novelty of this approach lies rather in doing all of these things at once.Further possible work lies in several directions. From an implementationpoint of view, investigation into more advanced scheduling techniques, and dis-tributed implementations would be useful. Work also needs to be done onmethods for verifying that AORTA designs satisfy timed logic predicates (i.e.formal speci cations), as well as extending (perhaps annotating) AORTA de-signs to include information about data within the system. This would allowfor functional as well as temporal veri cation, and the resolution of some ofthe nondeterminism in the system. Finally, tool support is crucial, and thereare many areas which would gain from computer assistance. Although sometools already exist, including a simulator and code generator [37], work needsto be done on veri cation of designs, and calculation of time bounds from thedistribution and scheduling characteristics of the system.AcknowledgementsThe authors would like to thank the University of Northumbria at Newcastle andNorthern IT Research for their nancial support, and the anonymous refereesfor their comments.References[1] R Milner. Communication and Concurrency. Prentice Hall, New York,1989.21 [2] C A R Hoare. Communicating Sequential Processes. Prentice Hall, NewYork, 1985.[3] International Standards Organisation. Informations processing systems -Open Systems Interconnection LOTOS A formal description techniquebased on the temporal ordering of observational behaviour, volume ISO 8807.ISO, 1989-02-15 edition, 1989.[4] R Cleaveland, J Parrow, and B Ste en. The concurrency workbench:A semantics-based tool for the veri cation of concurrent systems. ACMTransactions on Programming Languages and Systems, 15(1):36{72, Jan-uary 1993.[5] J C M Baeten and J A Bergstra. Real time process algebra. Formal Aspectsof Computing, 3(2):142{188, 1991.[6] T Bolognesi and F Lucidi. LOTOS-like process algebras with urgent ortimed interactions. In K R Parker and G A Rose, editors, Formal De-scription Techniques IV, FORTE '91, Sydney, pages 249{264. Elsevier,November 1991.[7] L Chen. An interleaving model for real-time systems. Technical ReportECS-LFCS-91-184, Edinburgh University, November 1991.[8] R Gerber and I Lee. A layered approach to automating the veri cation ofreal-time systems. IEEE Transactions on Software Engineering, 18(9):768{784, September 1992.[9] M Daniels. Modelling real-time behavior with an interval time calculus. InJ Vytopil, editor, Formal techniques in real-time and fault-tolerant systemsSecond international symposium, Nijmegen, Lecture Notes in ComputerScience 571, pages 53{71. Springer-Verlag, 1992.[10] H Hansson. A calculus for communicating systems with time and prob-abilities. In 11th real-time systems symposium, Lake Buena Vista, pages278{287. IEEE, 1990.[11] P Krishnan. A model for real-time systems. In 16th International Sym-posium on Foundations of Computer Science, Kazimierz, pages 298{307,1991.[12] G Leduc. An upward compatible timed extension to LOTOS. In K RParker and G A Rose, editors, Formal Description Techniques IV, FORTE'91, Sydney. Elsevier, November 1991.[13] F Moller and C Tofts. A temporal calculus of communicating systems. Tech-nical Report ECS-LFCS-89-104, Edinburgh University, December 1989.[14] J Quemada and A Fernandez. Introduction of quantitative relative timeinto LOTOS. In H Rudin and C H West, editors, Protocol Speci cation,Testing and Veri cation VII, Zurich, pages 105{121. Elsevier, 1987.[15] S Schneider, J Davies, D M Jackson, G M Reed, J N Reed, and A WRoscoe. Timed CSP: Theory and practice. In J W de Bakker, C Huizing,W P de Roever, and G Rozenberg, editors, Real-Time: Theory in Practice(REX workshop), Mook, Lecture Notes in Computer Science 600, pages640{675. Springer-Verlag, June 1991.22 [16] W Yi. Real-time behaviour of asynchronous agents. In CONCUR '90, Am-sterdam, Lecture Notes in Computer Science 458, pages 502{520. Springer-Verlag, 1990.[17] X Nicollin and J Sifakis. An overview and synthesis on timed processalgebras. In J W de Bakker, C Huizing, W P de Roever, and G Rozenberg,editors, Real-Time: Theory in Practice (REX workshop), Mook, LectureNotes in Computer Science 600, pages 526{548. Springer-Verlag, 1991.[18] J S Ostro . Formal methods for the speci cation and design of real-timesafety critical systems. Journal of Systems and Software, 18(1):33{60, April1992.[19] J M Spivey. The Z notation: A reference manual. Prentice Hall, New York,1989.[20] J S Ostro . A veri er for real-time properties. Real-Time Systems, 4(1):5{36, March 1992.[21] R Alur, C Courcoubetis, and D Dill. Model-checking for real-time sys-tems. In IEEE Fifth Annual Symposium On Logic In Computer Science,Philadelphia, pages 414{425, June 1990.[22] L Chen and A Munro. Applications of modal logic for the speci cationof real-time systems. In J C P Woodcock and P G Larsen, editors, For-mal Methods Europe '93, Odense, Lecture Notes in Computer Science 670,pages 235{249. Springer-Verlag, April 1993.[23] E A Emerson, A K Mok, A P Sistla, and J Srinivasan. Quantitative tem-poral reasoning. Real-Time Systems, 4(4):331{352, December 1992.[24] E Harel, O Lichtenstein, and A Pnueli. Explicit clock temporal logic. InIEEE Fifth Annual Symposium On Logic In Computer Science, Philadel-phia, pages 402{413, June 1990.[25] J Hooman. Compositional veri cation of real-time systems using extendedHoare triples. In J W de Bakker, C Huizing, W P de Roever, and G Rozen-berg, editors, Real-Time: Theory in Practice (REX workshop), Mook, Lec-ture Notes in Computer Science 600, pages 252{290. Springer-Verlag, June1991.[26] G Jones. Programming in occam. Prentice Hall, New York, 1987.[27] R Sisto, L Ciminiera, and A Valenzano. A protocol for multirendezvous ofLOTOS processes. IEEE transactions on computers, 40(1):437{446, April1991.[28] D J Hatley and I A Pirbhai. Strategies for Real-Time System Speci cation.Dorset House, New York, 1988.[29] S Bradley, W Henderson, D Kendall, and A Robson. Practical formaldevelopment of real-time systems. In 11th IEEE Workshop on Real-TimeOperating Systems and Software, RTOSS '94, Seattle, pages 44{48, May1994.[30] J F Groote. Transition system speci cations with negative premises. InJ C M Baeten and J W Klop, editors, CONCUR '90, Amsterdam, LectureNotes in Computer Science 458, pages 332{341. Springer-Verlag, 1990.23 [31] S Bradley, W Henderson, D Kendall, and A Robson. Designing and imple-menting correct real-time systems. In W-P de Roever, editor, Formal Tech-niques for Real-Time and Fault-Tolerant Systems FTRTFT '94, Lubeck(Toappear). Springer-Verlag, September 1994.[32] C Y Park. Predicting program execution times by analyzing static anddynamic program paths. Real-Time Systems, 5(1):31{62, March 1993.[33] C Y Park and A C Shaw. Experiments with a program timing tool basedon source-level timing schema. IEEE Computer, 24(5):48{57, May 1991.[34] P Puschner and Ch Koza. Calculating the maximum execution time ofreal-time programs. Real-Time Systems, 1:159{176, 1989.[35] A Burns. Scheduling hard real-time systems : a review. Software Engi-neering Journal, 6(3):116{128, May 1991.[36] C Douglass Locke. Software architecture for hard real-time applications:Cyclic executives vs. xed priority executives. Real-Time Systems, 4(1):37{52, March 1992.[37] S Bradley, W Henderson, D Kendall, and A Robson. A formally basedhard real-time kernel. Technical Report NPC-TRS-94-3, Department ofComputing, University of Northumbria, UK, 1994. To appear in November1994 edition of Microprocessors and Microsystems, special issue on hardreal-time kernels.[38] H Kopetz, A Damm, C Koza, M Mulazzani, W Swabl, C Senft, and R Zain-linger. Distributed fault-tolerant real-time systems: The MARS approach.IEEE Micro, 9(1):25{40, February 1989.[39] M Kooij. Linking speci cations with implementations. In K R Parkerand G A Rose, editors, Formal Description Techniques IV, FORTE '91,Sydney, pages 99{108. Elsevier, November 1991.24